ci: wire up extension-update-test (0.1.0 -> stable) - #19

Stacked on #18 (link 3/3 of the update+upgrade testing effort -- completes
checklist item 7 of advanced-extension-testing.md §10: CI wiring for the
extension-update test, on top of #18's local test/install/load.sql
three-mode machinery).

What this adds

• bin/test_existing -- the committed, parameterized
  install→guard→update→assert→run-suite script (subcommands:
  plant-guard, update, prepare-old, run-suite, update-scenario,
  diff-fresh), modeled on Postgres-Extensions/cat_tools's
  bin/test_existing. prepare-old is simpler than cat_tools's own (no
  BRIDGE_TO parameter -- see the script's header for why); update-check
  / update-check-version aren't needed here at all (also explained in the
  header).
• bin/structural_diff / bin/structural_diff.sql -- a generic
  per-extension structural comparison tool, copied near-verbatim from
  cat_tools (already written generically, no cat_tools-specific object
  names). Wired into update-scenario as assert_matches_fresh.
• extension-update-test CI job: installs 0.1.0 (+ its since-dropped
  count_nulls dependency), plants + proves the dependency guard, ALTER EXTENSION UPDATEs to the current version, structurally compares against
  a fresh stable install, then runs the full suite against the real
  updated database in existing mode. Runs on a single PostgreSQL major
  (the newest supported) -- 0.1.0 has no identified PG-version floor, so
  crossing the full matrix would add job count with no added coverage.
• pg-upgrade-stepwise CI job: ONE cluster starting at the floor
  PostgreSQL major with 0.1.0 installed, updated straight to the current
  version, then climbing every later supported major in sequence
  (12→13→...→18) via a real binary pg_upgrade per step, running the full
  suite and re-proving the dependency guard after every step. The
  changes job now also derives climb_pg (ascending PG-major list) from
  the same NEWEST/CURRENT_FLOOR constants the test job's matrix
  already uses.
• all-checks-passed's needs: list updated for both new jobs; top-of-file
  "Test strategy" comment updated to match.

A real per-repo adaptation from the cat_tools reference

bin/test_existing's dynamic version assertion derives the current
version from make -s print-EXTENSION_object_reference_VERSION, not
print-PGXNVERSION (which cat_tools's own script uses). object_reference
has already adopted the stable pseudo-version scheme (#18):
PGXNVERSION is frozen at 0.1.0 (the last real numbered PGXN release,
used for git tagging/dist) and no longer tracks the current build's
default_version once stable is in play -- cat_tools's PGXNVERSION
and default_version still happen to match, so this divergence wasn't
visible there. Confirmed directly: make -s print-PGXNVERSION → 0.1.0,
make -s print-EXTENSION_object_reference_VERSION → stable (the correct
one to assert against).

Known issue: pg-upgrade-stepwise currently fails, not a CI-wiring bug

The job's first real binary pg_upgrade step already exercises schema
analyze/freeze, pg_xact/pg_multixact copy, WAL resets, and the new
cluster's schema restore -- then fails restoring _sentry_mv
(pg_class heap OID value not set when in binary upgrade mode, see the
job's own comment in ci.yml for the full root-cause analysis: a
materialized view marked pg_extension_config_dump() cannot survive
binary pg_upgrade, confirmed as a general PostgreSQL limitation, not
anything object_reference-specific). Fixing _sentry_mv needs a
maintainer decision (it's load-bearing for object_reference's
restore-repair contract), so I haven't attempted one here -- this PR's CI
will stay red on pg-upgrade-stepwise/all-checks-passed until that's
resolved separately. Everything else (lint, the test matrix,
extension-update-test) is green; CI run:
https://github.com/Postgres-Extensions/object_reference/actions/runs/31049876539.

Verification

• make lint clean.
• Ran the full update-scenario flow locally against a real PostgreSQL 17
  cluster before pushing: 0.1.0 install → guard planted + proven → update
  to stable → structural diff clean → full suite green in existing
  mode (7/7 pgTAP files passing).
• EXIT-trap verification (per this container's own gotcha doc on
  RETURN vs EXIT traps under errexit): deliberately corrupted a
  comment on a real object_reference table post-update to force a genuine
  structural divergence, then ran diff-fresh directly. Confirmed (a) the
  script exited non-zero (FAIL: structural diff ..., exit code 1), and
  (b) the scratch *__fresh_ref reference database was still dropped by
  the EXIT trap despite the failure not being the trap-registering
  subshell's last command. Also confirmed via trap -p EXIT that the
  scratch database name is baked into the trap as a literal at
  registration time, not re-read from the variable when the trap fires.
• Independently reproduced the _sentry_mv root cause against a bare,
  non-extension materialized view in a scratch cluster to confirm it's
  general, not object_reference-specific (see the ci.yml comment).

Test plan

• make lint
• Local update-scenario dry run against a real cluster
• EXIT-trap deliberate-failure verification
• CI: lint / test matrix / extension-update-test green
• pg-upgrade-stepwise / all-checks-passed green -- blocked on the
  _sentry_mv issue above, needs a maintainer decision